
PmTENT cooperation treaty 

From the INTERNATIONAL BUREAU 



EO/US 
PCT/SG98/00003 



PCT 

NOTIFICATION OF ELECTION 
(PCT Rule 61.2) 


To: 

United States Patent and Trademark 

unice 

(Box PCT) 

Crystal Plaza 2 

Washington, DC 20231 

ETATS-UNIS D'AMERIQUE 

in its capacity as elected Office 


Date of mailing: 

22 July 1999 (22.07.99) 




International application No.: 

PCT/SG98/00003 


Applicant's or agent's file reference: 
FP 1043 


International filing date: 

16 January 1998 (16.01.98) 


Priority date: 


Applicant: 

HU, Jianetal 



1. The designated Office is hereby notified of its election made: 

| X | in the demand filed with the International preliminary Examining Authority on: 

28 June 1999 (28.06.99) 



| | in a notice effecting later election filed with the International Bureau on: 



2. The election | X | was 

| | was not 



made before the expiration of 19 months from the priority date or, where Rule 32 applies, within the time limit under 
Rule 32.2(b). 



The International Bureau of WIPO 
34, chemin des Colombettes 
1211 Geneva 20, Switzerland 



Facsimile No.: (41-22) 740.14.35 



Authorized officer: 

J. Zahra 

Telephone No.: (41-22)338.83.38 



Form PCT/IB/331 (July 1992) 



2735461 



EO/AU 
PCT/SG98/00003 

Paai ENT COOPERATION TREA i / 



From the INTERNATIONAL BUREAU 



PCT 

NOTIFICATION OF ELECTION 
(PCT Rule 61.2) 


To: 

Australian Patent Office 
P.O. Box 200 
Woden, ACT 2606 
AUSTRALIE 

in its capacity as elected Office 


Date of mailing: 

22 July 1999(22.07.99) 




International application No.: 

PCT/SG98/00003 


Applicant's or agent's file reference: 
FP1043 


International filing date: 

16 January 1998(16.01.98) 


Priority date: 


Applica nt: 

INSTITUTE OF SYSTEMS SCIENCE 



1 . The designated Office is hereby notified of its election made: 

| X | in the demand filed with the International preliminary Examining Authority on: 

28 June 1999 (28.06.99) 



| | in a notice effecting later election filed with the International Bureau on: 



2. The election | X | was 

| | was not 

made before the expiration of 19 months from the priority date or, where Rule 32 applies, within the time limit under 
Rule 32.2(b). 





Authorized officer: 


The International Bureau of WIPO 




34, chemin des Colombettes 




1211 Geneva 20, Switzerland 


J. Zahra 


Facsimile No.: (41-22)740,14.35 


Telephone No.: (41-22)338.83.38 



Form PCT/IB/331 (July 1992) 27 34726 



uopy tor tne tiecteo urtice (tu/ub) ku i /boao/uuuuj 

h """NT COOPERATION TREA ~" 



From the INTERNATIONAL BUREAU 



PCT 

NOTIFICATION OF THE RECORDING 
OF A CHANGE 

(PCT Rule 92bis.1 and 
Administrative Instructions, Section 422) 


To: 

GREENE-KELLY, James, Patrick 

Lloyd Wise 

Tanjong Pagar 

P.O. Box 636 

Singapore yluoib 

SINGAPOUR 


Date of mailing (day/month/year) 
05 June 2000 (05.06.00) 


Applicant's or agents file reference 
FP1043 


IMPORTANT NOTIFICATION 


International application No. 
PCT/SG98/00003 


International filing date (day/month/year) 

16 January 1998(16.01.98) 



1. The following indications appeared on record concerning: 

X the applicant [^] the inventor the agent [^] the common representative 


Name and Address 

INSTITUTE OF SYSTEMS SCIENCE 

National University of Singapore 

Heng Mui Keng Terrace 

Kent Ridge 

Singapore 119597 

Singapore 


State of Nationality 
SG 


State of Residence 
SG 


Telephone No. 


Facsimile No. 


Teleprinter No. 


2. The International Bureau hereby notifies the applicant that the following change has been recorded concerning: 

X the person X the name X the address | j the nationality | | the residence 


Name and Address 

KENT RIDGE DIGITAL LABS 
21 Heng Mui Keng Terrace 
Singapore 119613 
Singapore 


State of Nationality 

SG 


State of Residence 
SG 


Telephone No. 


Facsimile No. 


Teleprinter No. 


3. Further observations, if necessary: 


4. A copy of this notification has been sent to: 
| X| the receiving Office | | the designated Offices concerned 
| [ the International Searching Authority | X| the elected Offices concerned 
| X | the International Preliminary Examining Authority | | other: 



The International Bureau of WIPO 


Authorized officer 




34, chemin des Colombettes 


Aino Metcalfe 


121 1 Geneva 20, Switzerland 




Facsimile No.: {41-22) 740.14.35 


Telephone No.: (41-22)338.83.38 



Form PCT/IB/306 (Ma rch 1 994) 003329502 



PATENT COOPERATION 

PCT 



5iTY 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 

(PCT Article 36 and Rule 70) 




Applicant's or agent's file reference 

FP1043 



FOR FURTHER ACTION 



See Notification of Transmittal of International Preliminary 
Examination Report (Form PCT/IPEA/416) 



International application No. 

PCT/SG 98/00003 



International filing date {day/month/year) 

16 January 1998(16.01.98) 



Priority Date {day/monti 



TfffeCEIVEI). 



International Patent Classification (IPC) or national classification and IPC 

IPC 6 : H 04 L 9/32, G 06 F 12/14, G 06 F 12/16 



MAY 1 7 2002 

Technology Center j 



100 



* Applicant 

/Insitute of Systems Scigr^/NdLlunal University of Singapore et all 



I. This international preliminary examination report has been prepared by this International Preliminary Examination Authority 
and is transmitted to the applicant according to Article 36. 



This REPORT consists of a total of 

□ 



sheets, including this cover sheet. 



This report is also accompanied by ANNEXES, i.e., sheets of the description, claims and/or drawings which have been 
amended and are the basis for this report and/or sheets containing rectifications made before this Authority (see Rule 
70. 16 and Section 607 of the Administrative Instructions under the PCT). 



These annexes consist of a total of 



sheets. 



This report contains indications relating to the following items: 
I \^] Basis of the report 



II 


□ 


III 


□ 


IV 


□ 


V 




VI 


□ 


VII 


□ 


VIII 


□ 



Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 



Date of submission of the demand 

28 June 1999 (28.06.99) 


Date of completion of this report 

26 May 2000 (26.05.00) 


Name and mailing address of the IPEA/AT 
Austrian Patent Office 
Kohlmarkt 8-10 
A-1014 Vienna 
Facsimile No. t/53424/200 


Authorized officer 

Hajos 

Telephone No. 1/53424/410 



Form PCT/IPEA/409 (cover sheet) (July 1998) 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



International application No. 

PCT/SG 98/00003 



Basis of the report 



3. 



With regard to the elements of the international application:* 
^ the international application as originally filed 
I I the description: 



pages 
pages 
pages 



, as originally filed 

, filed with the demand 



filed with the letter of _ 



I I the claims: 

pages 

pages 

pages 

pages 



, as originally filed 

. , as amended (together with any statement) under Article 19 
, filed with the demand 



filed with the letter of 



I I the drawings: 

pages 

pages 

pages 



, as originally filed 

, filed with the demand 



. , filed with the letter of _ 



I I the sequence listing part of the description: 

pages 

pages 

pages 



, as originally filed 

, filed with the demand 



. , filed with the letter of _ 



With regard to the language, all the elements marked above were available or furnished to this Authority in the language in 
which the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language which is: 

I I the language of a translation furnished for the purposes of international search (under Rule 23. 1(b)). 
I I the language of publication of the international application (under Rule 48.3(b)). 

I I the language of the translation furnished for the purposes of international preliminary examination (under Rule 55.2 and/ 
or 55.3). 

With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international 
preliminary examination was carried out on the basis of the sequence listing: 

I I contained in the international application in written form. 

I I filed together with the international application in computer readable form. 

I I furnished subsequently to this Authority in written form. 

I I furnished subsequently to this Authority in computer readable form. * 

I 1 The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 
international application as filed has been furnished. 

I | The statement that the information recorded in computer readable form is identical to the written sequence listing has 
been furnished. 

I | The amendments have resulted in the cancellation of: 

I I the description, pages . 

I I the claims, Nos. . 

I I the drawings, sheets/fig . 



5. Q This report has been established as if (some of) the amendments had not been made, since they have been considered to go 
beyond the disclosure as filed, as indicated in the Supplemental Box (Rule 70.2(c)).** 

* Replacement sheets which have been furnished to the receiving Office in response to an invitation under Article 14 are referred to 
in this report as „ originally filed" and are not annexed to this report since they do not contain amendments (Rules 70. 16 and 
70.17). 

* * Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this report. 



Form PCT/IPE A/409 (Box I) (July 1998) 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



International application No. 

PCT/SG 98/00003 



V. Reas ned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 

citations and explanations supporting such statement 



1 . Statement 



Novelty (N) Claims L35 L YES 

Claims NO 



Inventive step (IS) Claims 1.35 . YES 

Claims . NO 

Industrial applicability (IA) Claims ^35 . YES 

Claims NO 



2. Citations and explanations (Rule 70.7) 

The following documents are cited in the Search Report: 



EP 166541 A2 
EP 033833 A2 
EP 547975 Al 
WO 96/02993 A2 
EP 561150 A2 
EP 582827 A2 



EP 166541 A2 shows a communications network in which a plurality of costumer terminals are 
connected by communication lines to a single central terminal. Customer terminals are equipped 
with insertable portable cards, which are enciphering devices. The central terminal is equipped with 
a portable insertable card, which is a deciphering device. Central terminal comprises a recording 
device for recording the enciphered message and an output device for printing out the message 
deciphered by the portable insertable card of the central terminal. 

EP 33833 A2 relates to a transaction execution system having a central data base at a host data 
processing system, which is in communication with remote terminals. A transaction at a terminal is 
authorised based upon correspondence of personal identification data entered by the terminal 
operator at a keyboard with account identification data read from an account card by a card reader. 

EP 547975 Al discloses an arrangement for authentication of portable electronic cards placed in a 
terminal connected by transmission line to a remote system. 

WO 96/02993 A2 discloses a system for using digital signatures in a commercial cryptographic 
system that allows industry-wide security policy and authorization information to be encoded into 
the signatures and certificates by employing attribute certificates to enforce policy and authorisation 
requirements. 

EP 561 150 A2 shows a communication network used for transmission of data between detectors 
and a host processor, in which programmes are implemented for verifying received data. 



Continuation: Supplemental Box 



Form PCT/IPEA/409 (Box V) (July 1998) 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



International application No. 

PCT/SG 98/00003 



Supplemental Box 

(To be used when the space in any of the preceding boxes is not sufficient) 
Continuation of: Box V 

EP 0 582 827 A2 relates to a receiver having means for error correction of interleaved j 
pseudorandom data. 

EP 0 166 541 A2 and EP 0 033 833 A2, coming closest to the subject-matter of the present 
application, show systems comprising central data storage means, which are in 
communication with remote user terminals and means for establishing a digital data 
transaction session in which an authorised user is able to instruct storage or retreavel of a 
digital data item in association with the users account. 

However, non of the cited documents disclose means for encoding the digital data item into a 
plurality of parts, the parts being separately stored in the storage means. 
Therefore, the subject-matter of claims 1-35 can be considered novel and involving an 
inventive step. 

Industrial applicability is given. 



Form PCT/IPEA/409 (Supplemental Box) (July 1998) 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 




(11) International Publication Number: 


WO 99/37054 


H04L 9/32, G06F 12/14, 12/16 


Al 


(43) International Publication Date: 


22 July 1999 (22.07.99) 



(21) International Application Number: PCT/SG98/00003 

(22) International Filing Date: 16 January 1998 (16.01.98) 



(71) Applicant (for all designated States except US): INSTITUTE 
OF SYSTEMS SCIENCE [SG/SG]; National University of 
Singapore, Heng Mui Keng Terrace, Kent Ridge, Singapore 
119597 (SG). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): HU, Jian [CN/SG]; BLK 
302 #11-531, Clementi Avenue 4, Singapore 120302 (SG). 
BAO, Feng [CN/SG]; BLK 351 #04-57, Clementi Avenue 
2, Singapore 120351 (SG). DENG, Huije [SG/SG]; 57 West 
Coast Lane, Singapore 127787 (SG). 

(74) Agent: GREENE-KELLY, James, Patrick; Lloyd Wise, Tan- 
jong Pagar, P.O. Box 636, Singapore 910816 (SG). 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, 
GH, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, 
LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, 
PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, 
UA, UG, US, UZ, VN, YU, ZW, ARIPO patent (GH, GM, 
KE, LS, MW, SD, SZ, UG, ZW), Eurasian patent (AM, AZ, 
BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE, 
CH, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, 
PT, SE), OAPI patent (BF, BJ, CF, CG, CI, CM, GA, GN, 
ML, MR, NE, SN, TD, TG). 



Published 

With international search report. 



(54) Title: A METHOD OF DATA STORAGE AND APPARATUS THEREFOR 
(57) Abstract 

A method and apparatus for implementing a digital valuables depository 
system, for public or corporation users to store and to retrieve valuable digital 
information electronically is described. The apparatus is the electronic analogy 
to the physical safe boxes provided by banks whereby customers can keep their 
valuable belongings. The digital valuable depository service is provided by a 
Service Provider (SP). To make use of the services, a user first opens a Digital 
Safe account with the SP. The user can then deposit digital valuables into, as 
well as retrieve, copy and delete them from its account, all being carried out in 
an authentic and secure manner. To store a digital valuable, the SP first encodes 
it into N parts based on an encoding algorithm, and then stores the N parts 
into one or more data storage devices. To retrieve or copy a digital valuable 
which has been stored previously, the SP reads the N parts from corresponding 
storage devices, and recovers the digital valuable from the N parts based on a 
decoding algorithm. The encoding and decoding algorithms are selected such 
that the original digital valuable is recovered correctly even if some of the N 
parts are lost or corrupted. To avoid storage error/corruption accumulation, the 
system periodically checks the N parts of every stored digital valuables and 
recovers/corrects lost/corrupted parts when they are detected. 



Service 
Provider 



10 




Transmission 
Channel 



E 



20 



25 



30 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


sz 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


UZ 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


CI 


Cdte d' I voire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






cu 


Cuba 


KZ 


Kazakstan 


RO 


Romania 






cz 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







WO 99/37054 ] PCT/SG98/00003 

A METHOD OF DATA STORAGE AND APPARATUS THEREFOR 



BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to the field of data processing, and more particularly, but not 
exclusively, to a method and apparatus for implementing a system which is able to provide 
digital storage services for public or corporate users. 

Description of the Related Art 

The explosive growth in automatic information systems and their interconnections via 
"cyberspace" has increased the dependence of both organizations and individuals on the 
information processed, stored and communicated using these systems. Some of the 
information, hereinafter called digital valuables or valuables for short - whether it be text, 
graphics, animation, video, audio, all types of data, or software (such as source code or 
machine code) written in various programming languages, are very precious for a user - 
whether the user is an organisation or individual, and need be kept in a safe place from 
which the valuables can be retrieved reliably and securely at a later stage. Examples of 
such digital valuables are patients* medical records, financial transactions, various 
certificates, proprietary business data, electronic money, and legal documents. 

Currently, a user's digital information is commonly stored in the user's computer or in a 
networked file server. There are several fundamental problems with such an approach in 
that, firstly, it lacks integrity protection. Digital information is inevitably in digital format. 
The information is easy to tamper with, and the modifications need not leave any trace on 
the physical medium. In many situations it is necessary for a user to verify that the 
information retrieved is indeed what was stored in the first place and any modification to 
the information by system faults or malicious process can be detected. The second problem 
is low reliability. A hard disk or floppy disk may crash, resulting in irreversible loss of 
data. A networked file server provides higher reliability than a local hard disk but loss of 
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data is not uncommon. Moreover, such servers lack adequate security protection and are 
not easily accessible to public users. The third problem with the current technology of 
storing information is that it has little confidentiality protection. 

It is an object of the invention to alleviate at least one disadvantage of the prior art. 



SUMMARY OF THE INVENTION 



According to the invention in a first aspect, there is provided a digital data depository for 
storing digital data items for a user comprising: 
data storage means; 

a user account associated with the user; 

means for communication with the user; 

means for authentication of the user with the depository; 

means for establishing a digital data transaction session in which the user is able to instruct 

storage or retrieval of a digital data item in association with the user's account; 

means for encoding the data item into a plurality of parts, the parts being separately stored 

in the storage means;and 

means for decoding the encoded data item. 

According to the invention in a second aspect, there is provided a method of storing digital 
data items for a user comprising the steps of: 
providing a user account associated with the user; 
authenticating the identity of the user; 

receiving a digital data item and an instruction from the user for the item to be stored in 
association with the user's account; and 

encoding the data item into a plurality of parts and storing the parts separately. 

According to the invention in a third aspect, there is provided a method of protecting 
digital data comprising: 

providing a data depository in which digital data may be stored electronically; 

providing for registration of users of the data depository, each user having an 



WO 99/37054 3 PCT/SG98/00003 

account with the depository; 

in response to a request from a user, opening a transaction session with the user in 
which the user and the depository authenticate each other and performing a transaction 
instructed by the user in respect of a digital data item, the transaction being selected by the 
user from a plurality of available transactions including storage of the item in or retrieval 
of the item from the depository. 

The described embodiment of the present invention discloses a method for implementing 
a digital valuables depository system, for public or corporate users to store and to retrieve 
precious digital information. The described embodiment is the electronic analogy to the 
physical safe boxes provided by banks whereby customers can keep their precious 
belongings. There are two generic entities in the system, a Service Provider (SP) and a 
User, the SP operating and provides Digital Safe services to the User. To make use of the 
service, the User first registers with the SP to open an account. The User can then deposit 
digital valuables into, retrieve and delete them from its account, all being carried out in 
an authentic and secure manner. 

The SP ensures high reliability in storing users' digital valuables. To store a valuable, the 
SP first encodes each valuable into N parts based on an encoding algorithm, and then stores 
the N parts into one or more data storage devices. To retrieve or copy a valuable which has 
been stored previously, the SP reads the N parts from corresponding storage devices, and 
recovers the valuable from the N parts based on a decoding algorithm. The encoding and 
decoding algorithms are chosen such that the original valuable can be recovered correctly 
even if some of the N parts are lost or corrupted. To avoid storage error/corruption 
accumulation, the system periodically checks the N parts of every stored valuables and 
recovers/corrects lost/corrupted parts when they are detected. 

BRIEF DESCRIPTION OF THE DRAWINGS 



An embodiment of the invention will now be described, by way of example, with reference 
to the accompanying drawings in which: 
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FIG. 1 is a schematic diagram of a data storage system, being an embodiment of the 
invention. 

FIG. 2 shows a possible data structure of the User Account maintained by the Service 
Provider (SP) in the preferred embodiment of the present invention. 

FIG. 3 shows the steps to allow the User accessing his account in the preferred embodiment 
of the present invention. 

FIG. 4(a) illustrates a possible logical structure of the Transaction Request message of type 
Valuable Storage (VS_Req) in accordance with the preferred embodiment of the present 
invention. 

FIG. 4(b) illustrates a possible logical structure of the Transaction Request message of type 
Valuable Copy (VC_Req) in accordance with the preferred embodiment of the present 
invention. 

FIG. 4(c) illustrates a possible logical structure of the Transaction Request message of type 
Valuable Deletion (VD_Req) in accordance with the preferred embodiment of the present 
invention. 

FIG. 4(d) illustrates a possible logical structure of the Transaction Request message of type 
Valuable Retrieval (VR_Req) in accordance with the preferred embodiment of the present 
invention. 

FIG. 4(e) illustrates a possible logical structure of the Transaction Request message of type 
Account Status Report (ASR_Req) in accordance with the preferred embodiment of the 
present invention. 

FIG. 4(f) illustrates a possible logical structure of the Transaction Request message of type 
Session Close (SC__Req) in accordance with the preferred embodiment of the present 
invention. 
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FIG. 5(a) illustrates a possible logical structure of the Transaction Response message of 
type Valuable Storage (VS_Resp) in accordance with the preferred embodiment of the 
present invention. 

FIG. 5(b) illustrates a possible logical structure of the Transaction Response message of 
type Valuable Copy (VC_Resp) in accordance with preferred embodiment of the present 
invention. 

FIG. 5(c) illustrates a possible logical structure of the Transaction Response message of 
type Valuable Deletion (VD_Resp) in accordance with the preferred embodiment of the 
present invention. 

FIG. 5(d) illustrates a possible logical structure of the Transaction Response message of 
type Valuable Retrieval (VR_Resp) in accordance with the preferred embodiment of the 
present invention. 

FIG. 5(e) illustrates a possible logical structure of the Transaction Response message of 
type Account Status Report (ASR_Resp) in accordance with the preferred embodiment of 
the present invention. 

FIG. 5(f) illustrates a possible logical structure of the Transaction Response message of 
type Session Close (SC_Resp) in accordance with the preferred embodiment of the present 
invention. 

FIG. 5(g) illustrates a possible logical structure of the Transaction Response message of 
type Error (ERRResp) in accordance with the preferred embodiment of the present 
invention. 

FIG. 6 shows the flow diagram of a Transaction Response Program (TRP) used in the 
preferred embodiment of the present invention. 



FIG. 7 illustrates the flow diagram of the first Valuable Dispersal Program (VDP) used in 



WO 99/37054 PCT/SG98/00003 

6 

the preferred embodiment of the present invention. 

FIG. 8 shows the flow diagram of the first Valuable Recovery Program (VRP) used in the 
preferred embodiment of the present invention. 

FIG. 9 illustrates the flow diagram of the second Valuable Dispersal Program (VDP) used 
in the preferred embodiment of the present invention. 

FIG. 10 shows the flow diagram of the second Valuable Recovery Program (VRP) used in 
the preferred embodiment of the present invention. 

FIG. 1 1 shows the flow diagram of the first Valuable Checking and Correction Program 
(VCCP) used in the preferred embodiment of the present invention. 

FIG. 12 shows the flow diagram of the second Valuable Checking and Correction Program 
(VCCP) used in the preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Methods for implementing a digital data depository system,hereinafter referred to as Digital 
Safe, are described. The system is an electronic analogy to the physical safe boxes provided 
by banks whereby customers can keep their precious belongings. In the following 
description, numerous specific details are set forth such as logical structures of digital 
information and program steps, etc. in order to provide a thorough understanding of the 
present invention. It will be obvious to one skilled in the art that the present invention may 
be practised without these specific details. In other instances, well known steps as those 
involved in public key and symmetric key cryptosystem operations, in computing digest of 
a message using a one-way hash function, in digital signature generation and verification, 
in encoding of a data item into a codeword in an error-control coding scheme, in error-and- 
erasure-correction decoding, in erasure-correction decoding, are not shown in order not to 
obscure the present invention. 
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The detailed description with respect to the implementation and operations of the Digital 
Safe system is presented partially in terms of algorithmic and symbolic representations of 
operations on data bits within the computer memory. These algorithmic descriptions and 
representations are the means used by those skilled in the art of data processing to most 
effectively convey the substance of their work to others skilled in the art. 

An algorithm is here, and generally, conceived to be a self-consistent sequence of steps 
leading to a desired result. These steps are those require physical manipulation of physical 
quantities. Usually, though not necessarily, these quantities take the form of electrical or 
magnetic signals capable of being stored, transferred, combined, and otherwise manipulated. 
In this case, the physical quantities are voltage or current signals which correspond to the 
digital valuables/information being processed. It proves convenient at times, principally for 
reason of common usage, to refer to these signals as bits, values, elements, symbols, 
characters, terms, items, fields, numbers or the like. It should be borne in mind, however, 
that all of these and similar terms are to be associated with the appropriate physical 
quantities and are merely convenient labels applied to these quantities. 

Furthermore, the manipulations performed are often referred to in terms such as adding or 
comparing, which are commonly associated with the mental operations performed by a 
human operator. No such capability of a human operator is necessary, or desirable. In most 
cases, in any of the operations described herein which form part of the present invention, 
the operations are machine operations. Useful machines for performing the operations of 
the present invention include general purpose digital computers or similar devices such as 
digital signal processors. In all cases, it should be borne in mind that there is a distinction 
between the method operation in operating a computer or other apparatus and the method 
of computation itself. The embodiment of the present invention to be described relates to 
method steps for secure and reliably storing users' digital valuables into and then 
subsequently retrieving them from a data depository system maintained and operated upon 
by a service provider. 
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The embodiment of the present invention also relates to an apparatus for performing these 
operations. This apparatus may be specially constructed for the required purpose or it may 
comprise general purpose computers as selectively activated or reconfigured by a computer 
program stored in the computers. The algorithms presented herein are not inherently related 
to any particular computer or other apparatus. In particular, various general purpose 
machines may be used with programs written in accordance with the teachings herein, or 
it may prove more convenient to construct specialized apparatus such as digital signal 
processor to perform the required method steps. The required structure for a variety of 
these machines would appear from the description given below. 



GENERAL SYSTEM CONFIGURATION 



A general model of the Digital Safe system is shown in FIG. 1. in which the Service 
Provider (SP) 10 provides data depository services to User 30 via a transmission channel 
20. The SP system is responsible for storing and retrieving the User's digital valuables in 
a secure, reliable, and authenticated manner. A digital valuable, or valuable for short, has 
an unique identifier and is a self-contained entity. There can be various types of valuables 
including but not restricted in form to text, graphics, animation, video, audio, software, or 
any combination thereof. The transmission channel 20 represents the means and more 
specifically the media through which communication messages are exchanged between the 
SP 10 and the User 30. Such messages include the User's requests to the SP over paths 25 
and 15 and the SP's responses to the User over paths 15 and 25. The transmission channel 
20 includes but is not limited to any communication means or media such as computer 
networks, radio links, satellite links, diskettes or other storage medium. It should be 
understood by one skilled in the art that the term User is interchangeable with any user of 
information. 

The described embodiment teaches methods for securely and reliably storing Users' 
valuables into and then retrieving them from the User's account maintained by the SP. 
These methods will be described with reference to specific steps of manipulating 
information. For one skilled in the art, it is obvious that some of these steps shall be best 
automated by, for example, implementing them as a special purpose software, which is 
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usually called a server, running on general purpose computers. It is clear that an 
information provider could simultaneously initiate multiple executions of the server to serve 
multiple end users. It is also clear that there may exist multiple SPs. For example, there 
may be one SP per organization or per district. 

For clarity of presentation, the description below will elaborate on the model having one 
SP and one User. It is also clear that a User may also be another SP. 



PREFERRED EMBODIMENT OF THE PRESENT INVENTION 
1. Overall System Set-Up 

Referring to FIG. 1, prior to using the Digital Safe services provided by the SP 10, the 
User 30 registers itself to the SP. During this registration process, the User authenticates 
itself to the SP by whatever means as required by the SP. The User agrees to the terms of 
a service contract. Such a contract contains at a minimum the identities, addresses of both 
the User and the SP, and the types of services to be provided by the SP. It may contain the 
public keys of the User and the SP, respectively. These keys are selected by the respective 
party based on certain public-key cryptosystems (PKCs). It may contain secret keys shared 
by the Users and the SP. The Digital Safe system relies on cryptographic protocols for 
mutual authentication between the User and the SP and for protecting the confidentiality 
and integrity of the User's valuables. Such cryptographic protocols require the User to 
possess cryptographic keys or secrets to operate. The contract may also specify the 
procedures for the User to recover lost cryptographic keys or secrets. 

Message authentication code (MAC) is used to protect the integrity of a message. A MAC 
of a message can be generated using a symmetric key cryptosystem with the message and 
a secret value as inputs or using a one-way hash function with the message and a secret 
value as inputs. Since both digital signature and MAC are used for message integrity 
protection and authentication, we will refer them as Integrity Check (IC). For further 
references on PKC, symmetric key cryptosystem, generation and verification of digital 
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signature, one-way hash functions, generation and verification of MAC, and public key 
certificate, see D. E. R. Denning, Cryptography and Data Security, Addition- Wesley, 
Reading, MA, 1983; W. Stallings, Network and Internetworks Security - Principles and 
Practice, Prentice Hall, Englewood Cliffs, NJ, 1995; and C. Kaufman, R. Perlman and M. 
Speciner, Network Security - Private Communication in a Public World, PTR Prentice Hall, 
Englewood Cliffs, NJ, 1995. 

At the end of the User registration, the SP sets up an account for the User. There are at 
least two types of accounts. In the first type, called flat-rate account, the User's account is 
allocated a fixed data storage quota and time interval (which may be extended or reduced 
at the User's request) and the service charge might be at a flat rate. In the second type, 
called flexible-rate account, the User's account has no fixed data storage quota and the User 
is charged by usage. 

The User's account might be represented by a data structure shown FIG. 2, which includes 
a unique Account number (Acc_No) 50, the User's identity (U_ID) 52, contact information 
54, optionally public keys or public key certificates 56, and information items 58 related 
to valuables stored in the account. Possible information items 58 are valuable identity 
(V_ID), type, size, time of submission, a protection flag (P_FLAG), an optional storage 
interval for flexible-rate account and pointers to locations where the N parts of the valuable 
are stored. 

The PFLAG takes two possible values, Encryption_Required and 
Encryption_Not_Required. If P_FLAG is set to Encryption_Required, then the valuable is 
encrypted by the SP and a pointer to the decryption key is kept in the account for each SP 
encrypted valuable. If P_FLAG is set to Encryption_Not_Required, then the valuable is not 
encrypted by the SP. The information items related to stored valuables will be empty 
initially and will be updated every time the User updates its account or when a valuable's 
storage interval expires. It should be noted that all the items in the User's account can be 
made visible to the User except the pointers to decryption keys and the pointers to storage 
locations, which are only accessible to and modifiable by the SP. 
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The Digital Safe services provided by the SP 10 to the User 30 include Valuable Storage 
(VS), Valuable Copy (VC), Valuable Retrieval (VR), Valuable Deletion (VD), and Account 
Status Report (ASR). The VS service lets the User store new valuables in its account; the 
VC service allows the User to get copies of its previously stored valuables from its account, 
the VD service lets the User remove one or more valuables from its account; the VR 
service permits the User to get copies of previously stored valuables and at the same time 
delete those valuables from his account; and the ASR service provides the User with its 
most recent account status report. 

FIG. 3 shows the steps a user follows in accessing its account in the preferred embodiment 
of the present invention. In FIG. 3, the User and the SP starts a transaction session by 
running a mutual authentication and a session key exchange protocol. The User 10 prepares 
an Open Request (0_Req) message and sends the 0__Req to the SP in step 100. The OJReq 
message is used to initiate the communications between the User and the SP, and more 
importantly, to authenticate the User to the SP. The 0_Req contains at least the User's 
account number Acc_No 50 and/or identity U_ID 52. It is integrity protected by an IC ( 
i. e., either the User's digital signature or a MAC) which can be verified by the SP. Upon 
receiving the 0_Req, the SP verifies its validity in step 110. If it is not valid, an alert 
signal is sent to the User and the SP in step 120. If it is valid, the SP generates an Open 
Response (0_Resp) message, sends it to the User and opens a session with the User in step 
130. The 0_Resp is used to authenticate the SP to the User. This is integrity protected by 
an IC (i. e., either the SP's signature or a MAC) which can be verified by the User. After 
receiving 0_Resp, the User checks its validity in step 140. An alert signal is sent to the 
User and/or the SP in step 150 if the Response is not valid; otherwise, the User proceeds 
to step 160. The objectives of 0_Req and 0_Resp are mutual authentication of the User 
and the SP, to negotiate a unique session identifier to bind the User's transaction with his 
account, and to negotiate session keys for encrypting and integrity protecting the follow on 
message exchanges during the entire session if the communication path between the User 
and the SP is not secure. There are many authentication and key distribution protocols in 
the literature (see, for example, C. Kaufman, R. Perlman, and M. Speciner, Network 
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Security - Private Communication in A Public World, PTR Prentice Hall, Englewood 
Cliffs, NJ. 1995) which fulfil these requirements. Such protocols can be used in place of 
0_Req and 0_Resp. 

Referring again to FIG. 3, following the successful opening of the transaction session, the 
User generates and sends a Transaction Request (T_Req) in step 160 to the SP. There are 
five types of T_Req messages corresponding to the five types of services: Valuable Storage 
Request (VS_Req), Valuable Copy Request (VC_Req), Valuable Deletion Request 
(VD_Req), Valuable Retrieval Request (VR_Req), Account Status Report Request 
(ASR__Req). In addition, there is a Session Close Request (SC_Req) which is used by the 
User to request closing of the current session. 

The possible logical structures of the six T_Req types in accordance with the preferred 
embodiment of the present invention are given in FIG. 4(a) - 4(f). 

FIG. 4(a) shows the structure of VS_Req. This logical structure comprises a session 
identifier (S_ID) 170 which was negotiated during steps 100 and 1 10 in FIG. 3 and is used 
here to identify uniquely the present session, a transaction type field VS_Req 175 which 
identifies the type of T_Req as Valuable Storage, a valuable identifier V_ID 180 which 
shows the identity of the submitted valuable, a field P_FLAG 182 which takes two possible 
values Encryption_Required and Encryption_Not_Required. The Encryption_Required value 
indicates that the User's valuable be encrypted by the SP before it is stored while the 
Encryption_Not_Required value indicates that the User's valuable be not encrypted by the 
SP before it is stored. The VS_Req message also contains a field V_By 185 which is the 
submitted valuable body, an optional field VJSI 188 which specifies the storage time 
interval of the submitted valuable (note that this field is not needed for flat-rate account), 
a freshness identifier F_ID_U 190 which guarantees that the message is fresh or in 
sequence, and a message IC field ICJJ 195. The V_By 185 may be in plaintext or in 
ciphertext. The latter is preferred if the User wants to keep the valuable confidential only 
to itself. The V_By contains the User's digital signature which can be used by either the 
User, or the SP, or an independent judge to verify the authenticity of the valuable. To 
simplify the presentation, only one V_ID and one V_By are shown here. In general, the 



WO 99/37054 PCT/SG98/00003 
message in FIG. 4(a) may contain multiple V_ID and multiple V_By fields, 

FIG. 4(b) depicts the structure of VC_Req. It comprises the S_ID 170, a transaction type 
field VC_Req 205 which identifies the type of T_Req as Valuable Copy, a valuable 
identifier V_ID 210 which shows the identity of the valuable to be copied, a freshness 
identifier F_ID_U 215 and a message IC field IC JJ 220. 

Possible logical structures of VD_Req and VR_Req are given in FIG. 4(c) and FIG. 4(d), 
respectively. In FIG. 4(c), the field VD_Req 225 indicates the type of T Req as Valuable 
Deletion and the field VID 230 shows the identity of the valuable to be deleted. In FIG. 
4(d), the field VRReq 245 indicates the type of the T_Req as Valuable Retrieval and the 
field V_ID 250 identifies the name of the valuable to be retrieved. 

To simplify the presentation, only one V_ID field is shown in FIG. 4(b) - 4(d). In general, 
each message in FIG. 4(b) - 4(d) may contain multiple V_IDs. 

FIG. 4(e) and FIG. 4(f) show the structures of ASR_Req and SC_Req, respectively. In FIG. 
4(e), the field ASRReq 265 indicates the type of TJReq as Account Status Report, and 
the field ASR_Option 270 specifies the format of the status report. Possible values of 
ASR_Option are FULL (in which case the SP will send the User a full version report, as 
specified in FIG. 2) and SHORT (in which case the SP will send the User a User selectable 
short version report). In FIG. 4(f), the SC_Req 285 indicates that the T_Req is of type 
Session Close. 

In FIG. 4(a) to FIG. 4(f), the F JD_U and the ICJJ fields are optional. They should be 
present if the communication path between the User and the SP is not integrity protected. 
The F_ID_U may be a timestamp, a sequence number, or a nonce (a non-repeating random 
number generated by SP and sent to the User in advance). The IC_U is computed over the 
entire message; it may be the User's digital signature generated using its private key or it 
may be a MAC generated using a secret key which is shared between the User and the SP. 
The User's digital signature must be used for the IC_U field whenever non-repudiation of 
origin of the T_Req messages is a requirement. 
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Referring to FIG. 3 again, upon receiving the T_Req in step 490, the SP processes it and 
prepares a Transaction Response (T_Resp) message using a Transaction Response Program 
(TRP) in step 500. There are at least seven types of T_Resp messages: Valuable Storage 
Response (VS_Resp), Valuable Copy Response (VC_Resp), Valuable Deletion Response 
(VD_Resp), Valuable Retrieval Response (VRResp), Account Status Report Response 
(ASRResp), Session Close Response (SC_Resp), and Error Response (ERR_Resp). FIG. 
5(a) - 5(g) show possible logical structures of the seven Transaction Response types in 
accordance with the preferred embodiment of the present invention. 

FIG. 5(a) is the structure of VS_Resp. It comprises a session identifier (S_ID) 170 which 
was negotiated during steps 100 and 110 in FIG. 3 and is used here to uniquely identify 
the present session, a field VS_Resp 300 which indicates the type of T_Resp as Valuable 
Storage, V_ID 180 taken from FIG. 4(a), a field VS_ACK 305 which indicates the success 
or failure of the transaction processing, a freshness identifier F_ID_SP 310 which 
guarantees that the message is fresh or in sequence, and a message IC field IC_SP 315. 

FIG. 5(b) is the structure of VC_Resp. It consists of S_ID 170, a field VC_Resp 320 which 
identifies the T_JResp as type Valuable Copy, V_ID 210 taken from FIG. 4(b), the copied 
valuable V_By 325 as specified by V_ID, a field VC_ACK 327 indicating the success or 
failure of the transaction processing, the fields FIDSP 330 and IC_SP 335. 

FIG. 5(c) is the structure of VDJResp. It consists of SJD 170, a field VD_Resp 340 which 
identifies the TResp as type Valuable Deletion, V_ID 230 taken from FIG. 4(c), a field 
VDACK 342 indicating the success or failure of the transaction processing, the fields 
F_ID_SP 345 and IC_SP 350. 

FIG. 5(d) is the structure of VR_Resp. It consists of SJD 170, a field VRJResp 355 which 
identifies the T_Resp as type Valuable Retrieval, VJD 250 taken from FIG. 4(d), the 
retrieved valuable V_By 360 as specified by V_ID, a field VRACK 362 showing the 
success or failure of the transaction processing, the fields F_ID_SP 365 and IC_SP 370. 

FIG. 5(e) is the structure of ARS_Resp. It comprises S__ID 170, a field ASR_Resp 375 
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which identifies the T_Resp as type Account Status Report, a field ASR_Report 380 with 
its format as specified by ASR_Option 270 in FIG. 4(e), a ASR_ACK field 382 indicating 
the success or failure of the transaction processing, the fields F_ID_SP 385 and IC_SP 390. 

FIG. 5(f) is the structure of SC_Resp. It consists of SJD 170, a field SC_Resp 395 which 
identifies the T_Resp as type Session Close, a field CS_ACK 398 indicating the success 
or failure of the transaction processing, the fields F_ID_SP 400 and IC_SP 405. 

FIG. 5(g) is the structure of ERR_Resp. It consists of S_ID 170, a field ERR_Resp 410 
which identifies the T_Resp as type ERROR, a field T_Req_Type 415, a field ERR_Status 
420, the fields F_ID_SP 425 and IC_SP 430. T_Req_Type indicates the type of T_Req 
with which the ERROR message is associated with. Possible values of T_Req_Type are 
VS_Req, VC_Req, VDJReq, VR_Req, ASR_Req, and SCJEteq. ERR_Status shows the type 
of errors which takes possible values such as "Request Not Verified" and "Request Not 
Permitted". 

In FIG. 5(a) to FIG. 5(g), the F_ID_SP and the IC_SP fields are optional. They should be 
present if the communication path between the SP and the User is not integrity protected. 
The F_ID_SP may be a timestamp, a sequence number, or a nonce (i. e., a non-repeating 
random number generated by the User and sent to the SP before hand). The ICSP is 
computed over the entire message; it may be the SP's digital signature generated using its 
private key or it may be a MAC generated using a secret key shared between the SP and 
the User. The former must be used if non-repudiation of origin of T_Resp messages are 
required. 

Referring again to FIG. 3, the SP sends the TResp to the User in step 1000. The T_Resp 
sent in step 1000 by the SP is received at the User side in step 1020. The User first verifies 
if TJResp is valid in 1030, including verifying the freshness of the freshness identifier 
F_ID_SP and the validity of the integrity check IC_SP. If the answer is "No", an alert 
signal is sent to the User and/or the SP in step 1040 and the User/SP will take actions 
accordingly. Assuming that the output of step 1030 is "Yes", the User then checks to see 
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if the received T_Resp is of type SC_Resp. If yes, the current session is closed; otherwise, 
it accepts and outputs the results of the T_Resp message in step 1055 and then goes back 
to step 160. 

3. Operations of the Transaction Response Program 

FIG. 6 shows the flow diagram of a Transaction Response Program (TRP) used in the 
preferred embodiment of the present invention. Referring to FIG. 6, the TReq received 
in step 490 in FIG.3 is first checked for its validity in step 520, including checking the 
validities of the freshness identifier F_ID_U and the integrity check ICMJ, as well as 
checking if the requested operation in T_Req is permitted. If the T_Req is not valid, a 
TJlesp of type ERR_Resp is formed in step 530, where the format of the ERRResp is 
as specified in FIG. 5(g). Assuming that TJReq passes the checking in step 520, it is next 
inspected in step 540 to see if it is of type SC_Req. If the answer is "Yes", the TRP closes 
the current session and prepares a T_Resp of type SC_Resp in step 550 according to the 
format of the T_Resp given in FIG. 5(f)* Assuming that the outcome in step 540 is "No", 
the T_Req is checked in step 560 to see if it is of type VSJReq. If yes, the TRP first 
processes and stores the submitted valuable using a Valuable Dispersal Program (VDP), 
updates the User's account (i. e., records the valuable's VID, time of storage, storage 
duration, pointers to storage locations, the value of P JFLAG and pointer to the decryption 
key if PFLAG = Encryption_Required), and then prepares a TResp of type VS_Resp in 
step 570 according to the format as specified in FIG. 5(a). If step 560 outputs "No", the 
T_Req is next inspected to see if it is of type VC_Rep in step 580. If yes, the TRP first 
recovers the requested valuable using a Valuable Recovery Program (VRP) and then 
prepares a T_Resp of type VC_Resp in 590, where the format of VC_Resp is according 
to FIG. 5(b). Assuming that step 580 yields "No", the T_Req is next checked in step 600 
to see if it is of type VD_Req, if the answer is "Yes", the TRP first deletes the valuable 
specified in TJReq and then prepares a T_Resp of type VD_Resp in step 610 according to 
the format as given in FIG. 5(c). Assuming that the outcome of step 600 is "No", the 
TJResp is next checked in step 620 for type VR_Req. If yes, the TRP first recovers the 
requested valuable using VRP, delete the valuable from the User's account, and prepares 
a TJlesp of type VR_Resp according to the format of FIG. 5(d), all being performed in 



WO 99/37054 PCT/SG 98/00003 

step 630. If the output of step 620 is "No", the T_Req must be of type ASR_Req. In this 
case, the TRP prepares a T_Req of type ASR_Req, with its format as given in FIG. 5(e). 
It should be noted that the T_Resp messages prepared in steps 530, 550, 570, 590, 610, 
630, and 640 are sent to the User in step 1000 in FIG. 3. The executions of the steps 540, 
560, 580, 600, 620, and 640 do not have to follow the order given above; they may be 
carried out in any order according to the preference if the system designer. 

4. Operations of the First Valuable Dispersal Program and the First Valuable Recovery 
Program 

FIG. 7 illustrates the flow diagram of the first Valuable Dispersal Program (VDP) used in 
the preferred embodiment of the present invention. The valuable to be processed by the 
VDP program has the valuable identifier V ID 180 and valuable body V_By 185 as 
specified by the VS_Req message shown in FIG. 4(a). The valuable contains the User's 
digital signature which can be checked by the User and the SP to verify its authenticity. 
The basic function of VDP is to transfer a submitted valuable into N parts based on an (N, 
K) error-control code C with symbols over Galois field GF(2 m ), where m is a positive 
integer. For further reference on encoding and decoding of a (N, K) error-control code, see 
R. E. Blahut, Theory and Practice of Error Control Codes, Addison- Wesley, Reading, MA, 
1983. Also see S. Lin and D. J. Costello, Jr., Error Control Coding: Fundamentals and 
Applications, Prentice-Hall, Englewood Cliffs, NJ, 1983. Referring to FIG. 7, the User's 
digital signature on the valuable is first checked in step 700. If it is valid, the VDP 
proceeds to step 705; otherwise it goes to step 530 in Fig. 6. In step 705, the VDP checks 
if the P_FLAG 182 field of the VS__Req message is set to Encryption_Required. If "No", 
the program proceeds to step 715; otherwise, the valuable is encrypted under a 
cryptographic key in step 710. In step 715, the valuable or its ciphertext from step 710 is 
divided into q K-tuples, Xj = (x n x j2 ... x iK ) in step 715, for i = 1 to q, where xij is a 
symbol over GF(2 m ). Each K-tuple X iy i = 1 to q, is then encoded into a codeword Y { = (y n 
y i2 ... y iN ) of the (N, K) error-control code C in step 720. Next, the q codewords Y i9 for i 
= 1 to q, are rearranged into N q-tuples, Z y = {y X} y 2j ... y^) in step 725, for j = 1 to N. 
Finally the q-tuples Zj, j = 1 to N, are stored into one or multiple data storage devices. 



WO 99/37054 PCT/SG98/00003 

18 

FIG. 8 shows the flow diagram of the first Valuable Recovery Program (VRP) which works 
in conjunction with the first VDP in the preferred embodiment of the present invention. To 
recover the valuable (with identifier V_ID) which was dispersed by the first VDP in FIG. 
7, the VRP first reads the N q-tuples Z'j = (y y }j y' 2j ... y^), for j = 1 to N, from the 
corresponding storage devices in step 740 using the storage location pointers in the User's 
account, where Z'j is the read version of Z y If Z'j can not be found due to various reasons 
such as storage device crash or corruption, Z'j is regarded as a q-tuple of "erasures", i. e., 
all the symbols in Z'j = (y',j y' 2j ... y'^-) are marked as "erasure". Next, the VRP rearranges 
N q-tuples Z'j, j = 1 to N, into q N-tuples Y'i= (y y n y' i2 ». y'jwX for i = 1 to q, in step 745. 
It should be noted that if Z'j is a q-tuple of "erasures", the jth symbol y*^ in Y'j is an 
"erasure". The N-tuple Y'^ (y'j, y' i2 ... y' jN ) is an erroneous codeword of the (N, K) code 
C, i.e., a codeword corrupted by errors and erasures. The q erroneous codewords Y*p= (y'j, 
y'i2 •** y\>j)> i - 1 to q, are input one by one to an error-and-erasure-correction decoder 
based on the (N, K) code C, to produce q K-tuples X*j= (x' n x' i2 ... x' iK ), i = 1 to q, in step 
750. If the errors and the erasures in Y\= (y* n y' i2 ... y' iN ) are correctable by the decoder, 
then X'j = X 4 . Step 755 checks to see if the q N-tuples are decoded successful. If not, an 
alarm is raised in step 765; if yes, the outputs of step 750, X\ 9 i = 1 to q, are concatenated 
in step 760. In step 770, the VRP reads the corresponding P_FLAG from the User's 
account and checks if it equals Encryption_Required. If "No", the program produces the 
required valuable (which is the output of step 760) in step 780; if "Yes", the program 
proceeds to step 775 where it decrypts the output of step 760 using the appropriate 
decryption key. The result of step 775 is the required valuable which is output in step 780. 

Let d denote the minimum Hamming distance of the (N, K) code C. Further, let e denote 
the number of erasures (i. e., lost symbols) and c the number of error symbols in Y* = (y' n 
y'a — y'iN)> respectively. By the theory of error-control coding, the decoder output will be 
correct, i. e., X\ = X t9 as long as e + 2c < d. In particular, for the so called maximum- 
distance codes, such as the Reed-Solomon codes, their minimum Hamming distance d = 
N - K + 1 . Therefore, given K, an N can almost be selected, such that the probability that 
a valuable cannot be recovered is smaller than a pre-determined threshold. 



5. Operations of the Second Valuable Dispersal Program and the Second Valuable 
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FIG. 9 illustrates the flow diagram of the second Valuable Dispersal Program (VDP) used 
in the preferred embodiment of the present invention. The valuable to be processed by the 
VDP program has the valuable identifier V_ID 180 and valuable body V_By 185 as 
specified by the VS_Req message shown in FIG. 4(a). The valuable contains the User's 
digital signature which can be checked by the User and the SP to verify its authenticity. 
The basic function of VDP is to transfer a submitted valuable into N parts based on an (N, 
K) error-control code C with symbols over Galois field GF(2 m ), where m is a positive 
integer. Referring to FIG. 9, the User's digital signature on the valuable is first checked in 
step 800. If it is valid, the VDP proceeds to step 810; otherwise it goes to step 530 in Fig. 
6. In step 810, the VDP checks if the P_FLAG 182 of the VS__Req message is set to 
Encryption_Required. If "No", the program proceeds to step 815; otherwise, the valuable 
is encrypted under an encryption key in step 812. In step 815, the valuable (if P_FLAG 
= Encryption_NotJRequired) or the output of step 812 (if P_FLAG = Encryption_Required) 
is divided into q K-tuples, X ; = (x n x i2 ... x iK ), for i = 1 to q, where xij is a symbol over 
GF(2 m ). Each K-tuple X i9 i = 1 to q, is then encoded into a codeword Y { = (y n y a ... y^) 
of the (N, K) error-control code C in step 820. The q codewords Y i5 for i = 1 to q, are 
rearranged into N q-tuples, Zj = (y,j y 2j ... y^) in step 825, for j = 1 to N. Next, an integrity 
check (as discussed under "Overall System Setup") ICj is computed over Z j5 j = 1 to N, 
in step 830. Finally the (Z j5 ICj), j = 1 to N, are stored into one or multiple data storage 
devices in step 835 with each Z y being stored together with its corresponding ICj. 

FIG. 10 shows the flow diagram of the second Valuable Recovery Program (VRP) which 
works in conjunction with the second VDP in the preferred embodiment of the present 
invention. To recover the valuable (with identity D_ID) which was dispersed by the VDP 
of FIG. 9, the VRP first reads the N q-tuples Z\ = (y^ y' 2j ... y^) and the associated 
integrity checks ICj, for j = 1 to N, from the corresponding storage devices in step 840, 
where ZVj is the read version of Zj and ICj is the read version of ICj. If Z'j can not be 
found due to various reasons such as storage device crash or corruption, ZVj is regarded as 
a q-tuple of "erasures", i. e., all the symbols in Z'j = (y' u y' 2j ... y'qj) are marked as 
"erasure". If Z'j is found, it will be integrity checked using IC'j. That is, an integrity check 
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is computed over Z'j and the result is compared with IC'j. If the two are equal, Z'j is 
considered error free; otherwise, Z'j is regarded as a q-tuple of "erasures". In step 845, the 
VRP checks to see if the number of erased Z'jS is less than d, the minimum Hamming 
distance of the (N, K) code. If not, it raises an alarm in step 850; if yes, the program 
proceeds to step 855 where the N q-tuples Z' j5 j = 1 to N, are rearranged into q N-tuples 
Y'r= (y'n y* i2 *•* Y'in)' for i = 1 to q. It should be noted that if Z'j is a q-tuple of "erasures", 
the jth symbol in Y\ is an "erasure". The N-tuple Y\= (y* n y' i2 ... y'^) is a codeword 
corrupted by erasures. The q N-tuples Y'j= (y* n y' i2 ••• y\>i)> i = 1 to q, are input one by 
one to an erasure-correction decoder based on the (N, K) code C, to produce q K-tuples 
X* = (x' n x' i2 ... x' iK ), i = 1 to q, in step 860. As long as the number of erasures in Y' s is 
less than d, the outputs of the decoder in step 860 will be correct. In step 865, the X',-, i 
= 1 to q, are concatenated together. In step 870, the VRP reads the corresponding P_FLAG 
from the User's account and checks if it equals Encryption_Required. If "No", the program 
produces the required valuable (which is the output of step 865) in step 880; if "Yes", the 
program proceeds to step 875 where it decrypts the output of step 865 using the appropriate 
decryption key. The result of step 875 is the required valuable which is output in step 880. 

6. Operations of Data Checking and Correction Programs 

To avoid error accumulations in the N parts of the stored valuable, all stored data is 
checked periodically (in regular or irregular interests) by a Data Checking and Correction 
Program (DCCP). The DCCP checks if all the N parts of a valuable are intact. If not, it 
corrects the errors and recovers the missing parts. 

There are two versions of DCCP. The first DCCP works in conjunction with the first VDP 
in section 4. Its flow diagram is shown in FIG. 11. In step 900, the DCCP collects the N 
q-tuples Z'j = (y' u y' 2j ... y' qj ), j = 1 to N, associated with the valuable identified by a 
given D_ID. If Z'j can not be found, DCCP marks Z'j as a q-tuple of "erasures", j = 1 to 
N. It then rearranges Z'j, j = 1 to N, into q N-tuples Y';= (y' u y' j2 ... y' iN ), i = 1 to q. In 
step 905, Y'j is decoded into X'j= (x' u x' i2 ... x' iK ), i = 1 to q, using an error-and-erasure- 
correction decoder of the (N, K) code C. Step 910 checks if all the q decoding operations 
in step 905 are successful. If not, an alarm is raised in step 915 and the program goes to 
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step 925; if yes, the DCCP proceeds to step 920. In step 920, X'j is encoded into Y";= 
(y"ii y"i2 y"iN)» i = 1 to q; the q N-tuples Y";, i = 1 to q, are rearranged into N q-tuples 
Z"j = (y",j y" 2j - y\), j = 1 to N; finally, the old q-tuples Z'j = (y\j y' 2j ... yV) in the 
storage devices are replaced by the new ones Z'j = (y",j y" 2j ... y"qj)> j = 1 to N. In step 
925, the DCCP checks to see if there are more stored valuables need to be checked. If not, 
the program terminates; if yes, it gets the D_ID of the valuable to be checked in step 930 
and goes back to step 900. 

The second DCCP works in conjunction with the second VDP in section 5 and its flow 
diagram is shown in FIG. 12. For a given D_ID of a stored valuable, the DCCP collects 
the data segments (Z'j, IC'j), j = 1 to N, which are associated with the valuable in step 
940. In step 945, the DCCP checks if all the N q-tuples Z'j = (y\ } y' 2j ... y^) are found 
and if they all pass the integrity check based on IC'j, j = 1 to N. If yes, the DCCP goes to 
step 975; if not, the DCCP proceeds to step 950 where the Z'j is marked as a q-tuple of 
"erasures" if it is not found or if it fails to pass the integrity check. Step 955 checks to see 
if the number of erased Z'jS is less d, the minimum Hamming distance of the (N, K) code 
C. If not, the DCCP raises an alarm in step 960 and then goes to step 975; if yes, the 
program proceeds to step 965. In step 965, the Z'j, j = 1 to N, are rearranged into Y' t = (y'j, 
y'i2 ••• y'iN)> i = 1 to q, which are then decoded one by one using an erasure-correction 
decoder of the (N, K) code C, into X' s = (x' n x' i2 ... x' iK ), i = 1 to q. In step 970, X\ is 
encoded into codeword Y" = (y" n y" i2 ... y^) of the (N, K) code C, i = 1 to q. The q 
codewords are then rearranged into q-tuples Z'j = (y"^ y f, 2j ... y"^), j = 1 to N. Finally, the 
DCCP computes the integrity check IC ,f j of Z"j, and replace the old (Z'j, IC'j) with the new 
(Z"j, IC"j) in the storage devices, j = 1 to N. In step 975, the DCCP checks if there are any 
more valuables need to be checked. If not, the program terminates and if yes, it fetches 
D_ID of the valuable to be checked in step 980 and then goes back to step 945. 

7. P rocedures for Key Recovery 

The User of the Digital Safe system needs to keep two sets of secret values, one for 
authentication to the SP in order to access its account and the other one for encrypting its 
valuables before submitting them to the SP. The former set of secret values are referred to 
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as User Authentication Secret Values (UASVs) and the latter set of secret values are 
referred to as Valuable Protection Secret Values (VPSVs). Examples of such secret values 
are private keys in public key cryptosystems and secret keys in symmetric key 
cryptosystems. All the secret values must be kept by the User in a secret and secure 
manner. An example of keeping a VPSV is to encrypt a valuable under the VPSV, encrypt 
the VPSV under a master key, and attach the encrypted VPSV with the valuable. 

Loss of the UASVs prevents the User from accessing its account on-line. In the event of 
the User losing its UASVs, the User approaches pre-deterrnined Key Escrow Agents to 
recover UASVs if UASVs are escrowed by such agents. Alternatively, the User will have 
to authenticate itself to the SP by other means (such as using paper documents) and upon 
authentication, the User and the SP separately or jointly establishing a new set of UASVs 
to replace the lost ones. The User from that point onwards uses the new UASVs to 
authenticate itself in order to access its account. 

Loss of VPSVs prevents the User from decrypting its encrypted data or verifying the 
authenticity of the retrieved/copied valuables from its account. To prevent this from 
happening, the User should keep multiple copies of the VPSVs or make use of the key 
recovery services provided by a key escrow system. In the event of the User losing its 
VPSVs, the User approaches Key Escrow Agents to recover lost VPSVs. If the lost VPSVs 
are not escrowed, then valuables encrypted by the lost VPSVs will be lost too. 
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Claims 

1. A digital data depository for storing digital data items for a user comprising: 
data storage means; 

a user account associated with the user; and 

means for establishing a digital data transaction session in which the user is able to instruct 

storage or retrieval of a digital data item in association with the user's account; 

means for encoding the data item into a plurality of parts, the parts being separately stored 

in the storage means;and 

means for decoding the encoded data item. 

2. A depository as claimed in Claim 1 wherein the data storage means comprises at 
least one data storage device, the parts being separately stored on the data storage device 
or devices. 

3. A depository as claimed in Claim 1 or Claim 2 further comprising means for 
communication with the user. 

4. . . A depository as claimed in any one of the preceding claims further comprising 
means for authentication of the user with the depository. 

5. A depository as claimed in any one of the preceding claims further comprising 
means for authentication of the depository by the user. 

6. A depository as claimed in any one of the preceding Claims wherein the user is able 
to instruct retrieval of a copy of the item in said transaction session. 

7. A depository as claimed in any one of the preceding Claims wherein the user is able 
to instruct deletion of the digital data item in said transaction session. 

8. A depository as claimed in any one of the preceding Claims wherein the user is able 
to instruct an account status report in said transaction session. 



PCT/SG98/00003 

23 



WO 99/37054 24 PCT/SG98/00003 

9. A depository as claimed in any one of the preceding Claims 

wherein the user's account has a data structure identifying the user and containing 
information identifying the data items stored therein. 

10. A depository as claimed in Claim 9 wherein the information of each data item 
includes at least one of the type, size, time/date of submission, period of storage and 
pointers to the locations of the stored parts of the data item. 

11. A depository as claimed in any one of the preceding Claims wherein the means for 
encoding: 

a) divides the data item into a multiple of q K-tuples, denoted as X> = (x n ... x iIC ), i = 
1 to q, where x y is a symbol over GF(2 m ) with m being a positive integer; 

b) for i = 1 to q, encodes X { into a codeword Y ( = (y u y i2 ... y iN ) using an (N, K) error- 
control code C, where Yy is a symbol over GF(2 m ); 

c) rearranges Y i? for i = 1 to q, into q-tuples Z } = (y xj y 2j ... y^), for j = 1 to N; and 

d) stores the Z j? for j = 1 to N, as said parts. 

12. A depository as claimed in claim 11 wherein the means for decoding : 

a) on inputting a data item identity, for j = 1 to N, reads Z'j = (y y xj y' 2j ... y'^) from the 
locations where Zj was stored, where Z j? j = 1 to N, are the parts of the data item as 
identified 

b) rearranges Z\j, for j = 1 to N, into N-tuples Y*j = (y\, y' i2 ... y\s), for i = 1 to q; 

c) decodes Y'j using an error-and-erasure-correction decoder of the (N, K) code C to 
obtain X\ = (x' n x' i2 ... x' iK ), for i = 1 to q;and 

d) concatenates X' i5 for i = 1 to q to form the data item. 

13. A depository as claimed in Claim 12 wherein the means for decoding: 

e) at step (a), if Zj cannot be found, assigns Z'j as a q-tuple of erasures 9 such that in 
Z\ = (y 5 ^ y' 2J ... yV) each symbol is marked as an erasure; otherwise leaving Z'j 
unchanged; 

f) checks to see if all the decoding operations are successful and if not, raises an alarm. 
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14. A depository as claimed in Claim 1 1 wherein the means for encoding computes an 
integrity check ICj over Z } for j=l to N and stores (Zj, ICj), for j=l to N, as said parts. 

15. A depository as claimed in Claim 14 wherein the means for decoding: 

a) on inputting a data item identity, for j = 1 to N, reads Z'j = (Y',j Y' 2j ... Y'^and IC'j 
from the locations where (Zj, Cj) was stored, where Zj, j = 1 to N, are the parts of the data 
item as identified and Cj are the parts of the corresponding integrity check 

b) rearranged Z'j, for j = 1 to N, into N-tuples Y\ = (y' n y' a ... y'^), for i = 1 to q; 

c) decodes Y\ using an error-and-erasure-correction decoder of the (N, K) code C to 
obtain X\ = (x' it x' j2 ... x' iK ), for i = 1 to q;and 

d) concatenates X' i5 for i = 1 to q to form the data item. 

16. A depository as claimed in Claim 15 wherein the means for decoding: 

e) at step (a), if Zj cannot be found, assigns Z'j as a q-tuple of erasures, such that in 
Z'j = (y\j y' 2j ... y'qj) each symbol is marked as an erasure; otherwise verifying the integrity 
of Z'j based on IC'j, if Z'j fails the integrity verification, marking it as a q-tuple of 
erasures; otherwise leaving Z'j unchanged; 

f) checks to see if all the decoding operations are successful and if not, raises an alarm. 

17. A depository as claimed in any one of the preceding claims further comprising 
means for encryption of the data item. 

18. A depository as claimed Claim 17 wherein the user is able to instruct encryption, 
prior to encoding, of the data item to be stored during the transaction session. 

19. A depository as claimed Claim 18 as dependent directly or indirectly on Claim 9 
wherein the information of each data item includes an indication of whether or not the item 
is encrypted and a pointer to a decryption key. 

20. A depository as claimed in any one of the preceding Claims further comprising 
means for decryption of an encrypted data item. 
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21. A depository as claimed in any one of the preceding Claims further comprising 
means for checking the encoded data items. 

22. A depository as claimed in Claim 21 wherein the means for checking decodes, 
checks and reencodes the data item at intervals. 

23. A depository as claimed in Claim 22 wherein the intervals are of fixed or variable 
period. 

24. A depository as claimed in any one of the preceding Claims 

further comprising means for verifying the integrity of the data item and the data item 
includes an integrity check to be verified. 

25. A depository as claimed in Claim 24 wherein the integrity check comprises a digital 
signature. 



26. A depository as claimed in Claim 24 wherein the integrity check comprises a 
message authentication code. 

27. A depository as claimed in any one of the preceding Claims wherein communication 
with the user during the transaction session is by means of a plurality of messages each 
associated with a transaction to be performed. 

28. A depository as claimed in Claim 27 wherein at least one of said messages contains 
a freshness identifier. 

29. A depository as claimed in Claim 28 wherein the freshness identifier comprises a 
timestamp, sequence number or a nonce. 

30. A method of operating a depository as claimed in any one of the preceding Claims. 
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31. A method of storing digital data items for a user comprising the steps of: 
providing a user account associated with the user; 

authenticating the identity of the user; 

receiving a digital data item and an instruction from the user for the item to be stored in 
association with the user's account;and 

encoding the data item into a plurality of parts and storing the parts separately. 

32. A method as claimed in Claim 31 further comprising the steps of: 

receiving an instruction to retrieve a stored and encoded data item, decoding the data item 
and sending the data item to the user. 

33. A method of protecting digital data comprising: 

providing a data depository in which digital data may be stored electronically; 

providing for registration of users of the data depository, each user having an 
account with the depository; 

in response to a request from a user, opening a transaction session with the user in 
which the user and the depository authenticate each other and performing a transaction 
instructed by the user in respect of a digital data item, the transaction being selected by the 
user from a plurality of available transactions including storage of the item in or retrieval 
of the item from the depository. 

34. A method as claimed in Claim 33 in which storage of the item includes encoding 
the item into a plurality of parts and storing the parts separately in the depository. 

35. A method as claimed in claim 33 or Claim 34 further comprising the step of 
checking, at intervals, the integrity of data items stored in the depository. 
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X'j — (x'jj X'j 2 ... X'j :< ) 
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Raise alarm 



Encode X' t into codeword Y", = (y"., y" i2 - >'"iN) ot the 
(N, K) code C, i = 1 to q. Rearrange the q codewords into 
q-tuples Z"j = (y"ij y" 2j ... y"^.), j = 1 to N. Delete Z'j from 

and store Z'j into data storage devices. 
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Get V ID of the Valuable to be checked next 



FIG. II 



WO 99/37054 



PCT/SG98/00003 



13/13 



^ Start ^ 



For a given v JD, collect the (Z j IC j), j = 1 to N, 
associated with the valuable. 
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Yes 




Mark Z' } as a q-tuple of "erasures" if Z\ is missing or if it 
f ai Is to pass the integrity check. 
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Raise alarm 



Rearrange Z'j j = 1 to K, into Y'j = (y'j I y' i2 ... y* |N ). i = 1 
to q. Decode Y^. fori = 1 to q, using the erasurer-correctior 
decoder of the (N, K) code C, intoX'j = (x'„ x* i2 ... x' iK ). 
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Encode X', into codeword Y", = (y";, y" i2 ... y''^) of the 
(N, K) code C, i = 1 to q. Rearrange the q codewords into 
q-tuples Z"j t= (/',. y" 2i ... y" .) and compute integrity 
check IC"., j = 1 to K. Delete (Z' y IC'.) from and store 
(Z'j, IC'j) into storage devices. 
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